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FOREWORD 


"A  Guide  to  Understanding  Design  Documentation  in  Trusted  Systems,”  is  the 
latest  in  the  series  of  technical  guidelines  that  are  being  published  by  the  National 
Computer  Security  Center.  These  publications  are  designed  to  provide  insight  to  the 
Trusted  Computer  Systems  Evaluation  Criteria  requirements  and  guidance  for 
meeting  each  requirement. 

The  specific  guidelines  in  this  document  provide  a  set  of  good  practices  related  to 
design  documentation  in  automated  data  processing  systems  employed  for 
processing  classified  and  other  sensitive  information.  This  technical  guideline  has 
been  written  to  help  the  vendor  and  evaluator  community  understand  what 
deliverables  are  required  for  design  documentation,  as  well  as  the  level  of  detail 
required  of  the  design  documentation  at  all  classes  in  the  Trusted  Computer  Systems 
Evaluation  Criteria. 

In  an  effort  to  provide  guidance,  there  will  be  recommendations  made  in  this 
technical  guideline  that  are  not  requirements  in  the  Trusted  Computer  Systems 
Evaluation  Criteria.  Any  recommendations  made  in  this  document  will  be  prefaced 
by  the  word  "should,”  whereas  all  of  the  criteria  requirements  will  be  prefaced  by  the 
word  "shall.” 

As  the  Director,  National  Computer  Security  Center,  I  invite  your  recommendations 
for  revision  to  this  technical  guideline.  We  plan  to  review  this  document  biannually. 
Please  address  any  proposals  for  revision  through  appropriate  channels  to: 

National  Computer  Security  Center 
9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 
Attention:  Chief,  Publications  Division 


6  October  1988 

National  Computer  Security  Center 
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1.  INTRODUCTION 


1.1  Purpose 

The  Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  is  the  standard 
used  for  evaluating  the  effectiveness  of  security  controls  built  into  Automated  Data 
Processing  (ADP)  systems.  The  TCSEC  is  divided  into  four  divisions:  D,  C,  B,  and  A, 
ordered  in  a  hierarchical  manner,  with  the  highest  division  (A)  being  reserved  for 
those  systems  providing  the  best  available  level  of  assurance.  Within  Divisions  C 
through  A  are  a  number  of  subdivisions  known  as  classes,  which  are  also  ordered  in  a 
hierarchical  manner  to  represent  different  levels  of  trust  in  these  classes. 

Design  Documentation  is  a  TCSEC  requirement  for  classes  Cl  and  above.  The 
purpose  of  this  guideline  is  to  provide  developers  of  trusted  computer  systems  with 
guidance  in  understanding  and  meeting  the  design  documentation  requirements 
contained  in  the  TCSEC.  To  accomplish  this,  the  guideline  addresses  two  goals. 
First,  the  guideline  increases  the  vendors’  awareness  of  the  importance  of  design 
documentation  to  the  security  of  their  system  throughout  the  system  life-cycle. 
Second,  the  guideline  forms  an  initial  basis  of  understanding  between  the  vendor 
and  evaluator  communities  concerning  what  is  expected  by  the  evaluation  team  in 
the  review  process  and  deliverables  for  design  documentation. 

Any  examples  in  this  document  are  not  to  be  construed  as  the  only 
implementation  that  will  satisfy  the  TCSEC  requirement.  The  examples  are  merely 
suggested  implementations.  The  recommendations  in  this  document  are  also  not  to 
be  construed  as  supplementary  requirements  to  the  TCSEC.  The  TCSEC  is  the  only 
metric  against  which  systems  will  be  evaluated. 

This  guideline  is  part  of  the  Technical  Guidelines  Program  to  provide  helpful 
guidance  on  TCSEC  issues  and  the  features  they  address. 


1.2  Scope 

Design  Documentation  is  a  TCSEC  requirement  for  classes  Cl  through  Al.  It 
is  one  of  the  four  types  of  documentation  required  by  the  TCSEC.  The  other  three 
documentation  requirements  are  for  a  Trusted  Facility  Manual  (TFM),  Security 
Features  Users  Guide  (SFUG),  and  Test  Plan  Documentation.  The  role  of  Design 
Documentation  is  to  identify  and  describe  the  Trusted  Computing  Base  (TCB)  and  its 
secui'ity  features.  Only  Design  Documentation  for  the  TCB  is  required  to  meet  the 
TCSEC  requirements,  but  it  is  strongly  recommended  that  design  documentation 
exist  for  the  entire  system.  Throughout  this  document,  the  word  system  will  be  used 
as  the  object  of  design  documentation  to  include  the  TCB  and  the  untrusted  portions 
of  the  system.  However,  it  should  be  emphasized  that  the  TCSEC  requirements  are 
based  solely  on  the  design  documentation  of  the  TCB. 

Design  Documentation  assists  vendors  during  the  system  life-cycle  by 
thoroughly  defining  the  policies  that  the  system  enforces.  It  also  provides  the 
material  by  which  the  evaluator  can  assess  whether,  and  to  what  degree,  the  design 
intent  was  carried  into  the  implementation.  The  design  documentation  is  intended 
to  guide  the  implementation  of  the  product;  it  is  not  intended  merely  as  an  abstract 
philosophical  exercise  completely  divorced  from  the  "real”  product. 
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Design  documentation  also  increases  the  developer’s  level  of  understanding  of 
the  system.  It  should  facilitate  the  correct  implementation  of  the  intended  behavior 
and  features  of  the  system,  This  guideline  will  discuss  design 

features  as  they  apply  to  computer  systems  and  products  that  are  being  built  wit 
the  intention  of  meeting  the  requirements  of  the  TCSEC. 


1.3  Control  Objective 

Each  of  the  TCSEC  requirements  serves  to  ensure  that  one  of  the  three  basic 
control  objectives  for  trusted  computing  -  security  policy,  accountability,  and 
assurance  -  are  satisfied.  Throughout  the  system  life-cycle  design 
aids  in  attaining  the  third  objective,  assurance,  by  helping  to  substantiate  claims 
for  the  completeness  of  access  mediation  and  degree  of  tamper  resistance.  L5J 

The  TCSEC  gives  the  following  as  the  Assurance  Control  Objective: 

"Systems  that  are  used  to  process  or  handle  classified  or  other  sensitive 
information  must  be  designed  to  guarantee  correct  and  accurate 
interpretation  of  the  security  policy  and  must  not  distort  the  intent  ot  that 
policy.  Assurance  must  be  provided  that  correct  implementation  and 
operation  of  the  policy  exists  throughout  the  system  s  life-cycle.  |5J 

Design  documentation  plays  an  important  role  in  providing  this  life-cycle 
assurance.  It  demonstrates  that  correct  implementation  and  enforcementofthe 
system’s  security  policy  exists  throughout  the  system  s  life-cycle.  As  it  relates  to  this 
control  objective,  design  documentation  facilitates  the  efforts  of  vendors  and  system 
developers  in  modifying  and  maintaining  the  system  throughout  its  life-cycle, 
without  compromising  the  trustworthiness  of  the  system. 

In  addition,  design  documentation  serves  as  a  useful  training  tool.  Design 
documentation  presents  a  technical  history  of  the  system,  containing  documentation 
on  past  changes  to  the  system  as  well  as  the  current  system.  It  can  used “J® 
training  of  new  systems  programmers  and  hardware  engineers  to  familiarize  them 

with  the  system. 
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2.  OVERVIEW  OF  DESIGN  DOCUMENTATION  PRINCIPLES 


Design  documentation  is  a  requirement  for  TCSEC  classes  Cl  and  above.  It 
provides  a  means  of  communicating  the  design  of  a  system  to  developers  that  enables 
them  to  comprehend  the  design  principles  of  the  system  and  to  make  changes  or 
upgrades  to  the  system  without  compromising  the  trustworthiness  of  the  system. 
The  information  contained  in  the  design  documentation  provides  a  rationale  as  to 
why  a  system  is  designed  as  it  is  and  whether  changes  to  the  system  will  alter  the 
intent  of  the  design. 

Design  documentation  plays  an  important  role  in  the  life-cycle  maintenance  of  a 
system  and  should  not  be  viewed  as  a  burden  to  system  development.  This  document 
should  help  developers  understand  the  importance  of  design  documentation  in  the 
life-cycle  of  computer  systems,  as  well  as  to  the  maintenance  of  trust  in  these 
systems.  Developers  should  recognize  the  importance  of  meeting  the  purpose  and 
intent  of  the  TCSEC  design  documentation  requirements  as  opposed  to  meeting 
them  in  a  strictly  mechanical  fashion. 


2.1  Purpose  of  Design  Documentation 

The  primary  purpose  of  design  documentation  is  to  define  and  describe  the 
properties  of  a  system.  As  it  relates  to  the  TCSEC,  design  documentation  provides 
an  explanation  of  how  the  security  policy  of  a  system  is  translated  into  a  technical 
solution  through  the  TCB  hardware,  software,  and  firmware. 

Design  documentation  explains  the  system’s  protection  mechanisms  so  that 
the  effect  a  change  may  have  on  the  security  of  the  system  can  be  evaluated  prior  to  a 
change  being  performed.  It  relates  the  TCSEC  requirements  to  the  architecture  of  a 
system  and  guides  the  implementation  of  the  system  under  development.  Complete 
documentation  ensures  that  the  vendor  has  an  understanding  of  what  elements  of 
the  system  are  protection  critical.  Design  documentation  explains  the  system  design 
to  the  vendor's  development  team  and  enables  the  developers  to  understand  the 
design  of  the  system  well  enough  to  maintain  the  system  and  to  perform  any 
necessary  changes  to  it  without  adversely  affecting  the  trustworthiness  of  the 
system.  In  addition,  the  design  documentation  assists  the  evaluators  by  providing 
them  with  a  vehicle  by  which  the  completeness  and  correctness  of  the 
implementation  can  be  assessed. 


2.2  Design  Documentation  Development  for  Evaluation 

Developers  should  incorporate  the  design  documentation  requirements  into 
the  system  development  process.  A  plan  that  addresses  each  design  documentation 
requirement  should  be  developed  early  in  the  development  phase  and  shared  with 
the  National  Computer  Security  Center  evaluators  to  ensure  the  thoroughness  of  the 
documentation. 
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Iterative  development  of  the  design  documentation  is  the  key  to  minimizing 
vendor  and  evaluator  efforts  during  the  evaluation  process.  Vendors  should  precede 
their  design  documentation  with  the  submittal  of  an  outline  of  the  design 
documentation  to  the  evaluators.  This  outline  should  contain,  among  other  things,  a 
statement  of  purpose  and  the  intended  audience  of  the  design  documentation.  Then, 
through  a  process  of  draft  submittal,  evaluator  comments  and  requests  for  additional 
information,  and  draft  revision  the  design  documentation  requirements  will  be  met. 
This  guideline  should  expedite  this  process  by  bringing  the  vendor's  first  drafts 
closer  to  evaluator  expectations  and  by  facilitating  convergence  between  vendor 
product  and  evaluator  expectations.  If  vendors  establish  a  dialogue  with  evaluators 
early  in  the  design  documentation  development  and  solicit  their  comments  on  early 
and  subsequent  drafts  of  the  design  documentation,  both  vendors  and  evaluators  will 
save  a  great  deal  of  time  and  effort  in  completing  the  evaluation  process. 


2.3  Level  of  Detail  of  Design  Documentation 

The  level  of  detail  of  design  documentation  will  determine  its  usefulness  and 
adequacy  in  meeting  the  TCSEC  requirements,  as  well  as  its  usefulness  to  the 
vendor  in  the  development  and  maintenance  of  the  system.  For  evaluators,  the  level 
of  detail  of  the  design  documentation  is  reviewed  to  ensure  that  the  system  developer 
understands  the  design  of  the  system  well  enough  to  make  changes  or  upgrades  to 
the  system  without  compromising  the  trustworthiness  of  the  system.  Design 
documentation  also  ensures  that  the  developer  understands  the  overall  security 
concepts  that  are  required  to  be  part  of  the  system  design.  How  well  the  security 
properties  of  the  system  are  documented,  and  how  this  information  is  integrated  into 
the  design  documentation  will  determine  whether  or  not  the  level  of  detail  of  the 
design  documentation  is  sufficient  in  meeting  the  TCSEC  requirements. 

The  design  documentation  shall  be  detailed  enough  to  serve  as  a  useful  tool 
for  vendor  maintenance  of  the  system  and  shall  clearly  indicate  what  elements  of  the 
design  impact  the  trustworthiness  of  the  system.  One  purpose  behind  design 
documentation  is  to  assist  vendors  in  maintaining  the  system  and  should  not  present 
a  burden  to  the  vendor  in  terms  of  quantity  or  detail.  A  good  rule  of  thumb  is.  that 
the  level  of  detail  of  design  documentation  should  be  sufficient  to  permit  an 
individual  with  a  degree  in  Computer  Science,  Electrical  Engineering,  or  the 
equivalent  with  knowledge  and  skills  in  programming,  hardware,  or  firmware 
development  to  understand  the  system  design  and  be  able  to  design  system 
modifications  without  adversely  affecting  trustworthiness  of  the  system. 


2.4  Level  of  Effort  for  Meeting  the  Requirements 

The  level-of  effort  necessary  for  developing  satisfactory  design  documentation 
has  historically  been  underestimated  because  the  intent  and  implications  of  the 
TCSEC  requirements  for  design  documentation  have  seldom  been  completely 
understood.  An  important  factor  to  consider  when  deciding  on  an  appropriate  level 
of  effort  is  the  importance  of  the  design  documentation  throughout  the  system  life- 
cycle.  Well  structured  design  documentation  that  is  carefully  planned  and  developed 
will  make  it  easier  to  understand  the  design  of  the  system. 


4 


The  level  of  effort  necessary  for  a  vendor  to  meet  the  design  documentation 
requirements  varies  from  system  to  system.  The  level  of  effort  generally  will  depend 
upon  the  necessary  level  of  detail,  which  depends  upon  the  class  of  evaluation  and 
the  complexity  of  the  system  being  evaluated.  The  requirements  for  TCSEC  classes 
Cl  and  C2  may  be  met  by  simply  following  good  engineering  documentation 
practices,  but  as  the  TCSEC  class  level  increases,  so  does  the  level  of  detail  and  effort 
necessary  for  meeting  the  TCSEC  requirements. 

In  terms  of  quantity,  the  length  of  design  documentation  at  the  higher  classes 
has  been  found  to  be  roughly  comparable  in  bulk  to  the  source  listings  of  the  overall 
system.  In  general,  producing  the  design  documentation  may  require  several  man 
months  to  a  man  year  of  system  development  time  at  Classes  Cl  and  C2,  and  up  to 
several  man  years  at  the  higher  classes.  Although  developing  design  documentation 
for  a  system  may  be  time  consuming,  this  time  will  be  amply  rewarded  by  the  ease  of 
system  maintainability  during  its  life-cycle. 


2.5  Format  of  Design  Documentation 

The  format  and  style  for  each  vendor's  design  documentation  is  specific  to  that 
vendor,  and  to  suggest  a  specific  format  would  restrict  vendors  in  developing  their 
design  documentation.  Although  this  guideline  addresses  distinct  requirements  for 
design  documentation,  it  should  not  be  assumed  that  separate  documents  are 
necessary  to  meet  each  requirement.  Indeed,  the  design  documentation  shall 
address  each  of  the  requirements,  but  it  is  acceptable  for  evaluators  to  be  pointed  to 
a  number  of  documents  to  address  a  specific  requirement.  Also,  graphics  serve  as  a 
useful  adjunct  to  design  documentation,  although  not  sufficient  alone  to  meet  the 
TCSEC  requirement  for  design  documentation.  Developers  may  choose  to  use 
graphics  to  describe  a  system  in  addition  to  other  design  documentation. 

Differences  among  computer  system  architectures,  designs,  and 
implementation  approaches  make  developing  a  standard  format  for  design 
documentation  inadvisable.  In  addition,  the  format  of  design  documentation  for  one 
system  may  be  totally  inappropriate  for  meeting  another  system's  needs.  The  format 
chosen  by  the  vendor  for  presenting  the  design  documentation  may  be  influenced  by 
business  concerns  other  than  expeditious  security  evaluation.  Different  design 
documentation  formats  present  different  advantages  and  challenges  to  evaluators 
and  different  advantages  and  costs  to  vendors  that  should  be  weighed. 

A  system's  design  may  be  evolutionary,  resulting  from  improvements  that 
build  upon  an  initial  version.  Maintaining  documentation  on  a  system  in  a 
release/update  form  may  be  convenient  for  a  developer.  However,  it  is  difficult  for 
new  developers  and  life-cycle  personnel  to  gain  an  understanding  of  the  overall 
system  architecture  from  documentation  that  describes  the  system  in  chronological 
terms  through  system  releases  and  updates.  To  be  useful,  these  updates  shall  be 
incorporated  into  the  design  documentation,  and  the  design  documentation  shall  be 
presented  as  a  complete  description  of  the  system,  and  not  the  initial  description  plus 
supplemental  sections  describing  changes. 
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3.  MEETING  THE  CRITERIA  REQUIREMENTS 

This  section  lists  the  TCSEC  requirements  for  design  documentation  at  each 
class.  All  of  these  requirements  have  been  extracted  from  the  TC  SEC  design 
documentation  requirements  and  include  explicit  and  implicit  design  documentation 
requirements,  where  necessary.  Each  numbered  requirement  is  referenced  in  the 
discussions  that  follow  in  Sections  4  and  5  of  this  document.  This  section  serves  as  a 
quick  reference  for  TCSEC  class  requirements. 

As  the  TCSEC  evaluation  class  level  increases,  it  is  implicitly  required  that  the 
design  documentation  be  more  detailed.  This  is  due  to  an  increase  in  assurance 
required  at  the  higher  classes,  as  well  as  the  introduction  of  new  features  at  the 
higher  classes  that  need  to  be  documented,  for  example,  labeling,  auditing. 


3.1  The  Cl  Design  Documentation  Requirements 

Requirement  1-  Describe  the  philosophy  of  protection. 

Requirement  2  -  Describe  how  the  philosophy  of  protection  is  translated 

into  the  TCB. 

Requirement  3  -  Describe  how  the  TCB  is  modularized  (if  modular). 

Requirement  4  -  Describe  all  interfaces  between  the  TCB  modules  (if 

modular). 

Requirement  5  -  Describe  how  the  TCB  protects  itself. 

Requirement  6  -  Provide  a  statement  of  the  system  security  policy. 


3.2  The  C2  Design  Documentation  Requirements 
No  new  requirements  have  been  added  at  the  C2  class. 


3.3  The  B 1  Design  Documentation  Requirements 

Requirement  7  -  Provide  an  informal  or  a  formal  description  of  the 

security  policy  model  enforced  by  the  TCB. 

Requirement  8  -  Explain  the  sufficiency  of  the  security  policy  model  to 

enforce  the  security  policy. 

Requirement  9  -  Identify  and  describe  the  TCB  protection  mechanisms. 

Requirement  10  -  Explain  how  the  TCB  mechanisms  satisfy  the  security 

policy  model. 
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3.4  The  B2  Design  Documentation  Requirements 


Requirement 

11- 

Describe  how  the  TCB  is  modularized. 

Requirement 

12- 

Describe  all  of  the  interfaces  between  the  TCB 
modules. 

Requirement 

13- 

Provide  a  formal  description  of  the  security  policy 
model. 

Requirement 

14- 

Prove  the  sufficiency  of  the  security  policy  model  to 
enforce  the  security  policy. 

Requirement 

15- 

Show  that  the  Descriptive  Top  Level  Specification 
(DTLS)  is  an  accurate  description  of  the  TCB  interface. 

Requirement 

16- 

Describe  how  the  TCB  implements  the  Reference 
Monitor  Concept. 

Requirement 

17- 

Describe  why  the  reference  monitor  is  tamper 
resistant. 

Requirement 

18- 

Describe  why  the  reference  monitor  cannot  be 
bypassed. 

Requirement 

19- 

Describe  why  the  reference  monitor  is  correctly 
implemented. 

Requirement 

20- 

Describe  how  the  TCB  is  structured  to  facilitate 
testing. 

Requirement 

21- 

Describe  how  the  TCB  is  structured  to  enforce  least 
privilege. 

Requirement 

22- 

Present  the  results  and  methodology  of  the  covert 
channel  analysis. 

Requirement 

23- 

Describe  the  tradeoffs  involved  in  restricting  covert 
channels. 

Requirement 

24- 

Identify  all  auditable  events  that  may  be  used  in 
exploitation  of  known  covert  storage  channels. 

Requirement 

25- 

Provide  the  bandwidths  of  known  covert  storage 
channels  whose  use  is  not  detectable  by  auditing 
mechanisms. 
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3.5  The  B3  Design  Documentation  Requirements 

Requirement 

26- 

Identify  all  auditable  events  that  may  be  used  in 
exploitation  of  known  covert  timing  channels. 

Requirement 

27- 

Provide  the  bandwidths  of  known  covert  timing 
channels  whose  use  is  not  detectable  by  auditing 
mechanisms. 

Requirement 

28- 

Describe  how  the  system  complies  with  additional  B3 
system  architecture  requirements,  for  example, 
minimal  TCB  and  layering. 

Requirement 

29- 

Informally  show  consistency  of  the  TCB 
implementation  (in  hardware,  firmware,  and  software) 
with  the  DTLS. 

Requirement 

30- 

Informally  show  correspondence  between  elements  of 
the  DTLS  and  elements  of  the  TCB. 

Requirement 

31- 

Informally  show  consistency  of  the  DTLS  with  the 
model. 

3.6  The  A1  Design  Documentation  Requirements 

Requirement 

32- 

Informally  show  consistency  of  the  TCB 
implementation  with  the  Formal  Top  Level 
Specification  (FTLS). 

Requirement 

33- 

Informally  show  correspondence  between  elements  of 
the  FTLS  and  elements  of  the  TCB. 

Requirement 

34- 

Clearly  describe  hardware,  software,  and  firmware 
internal  to  the  TCB  that  is  not  dealt  with  in  the  FTLS. 

Requirement 

35- 

Informally  or  formally  show  consistency  of  the  FTLS 
with  the  model. 

Requirement 

36- 

Informally  show  correspondence  between  the  FTLS  and 
the  DTLS'. 
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4.  COMPONENTS  OF  DESIGN  DOCUMENTATION 


Design  documentation  describes  why  a  system  is  trusted,  how  this  trust  is 
achieved,  the  mechanisms  which  provide  the  trust,  and  the  relevant  information 
that  makes  proper  maintenance  of  a  system  possible.  Design  documentation  at 
TCSEC  class  Cl  lays  the  foundation  for  trusted  systems  by  defining  the  philosophy 
of  protection  of  a  system.  As  the  TCSEC  classes  increase,  the  level  of  detail  and  the 
quantity  of  information  contained  in  the  design  documentation  shall  also  increase. 
The  following  sections  discuss  design  documentation  and  its  role  in  describing  the 
security  policy  of  the  system,  the  protection  mechanisms  of  the  system,  and  the 
specific  requirements  concerning  covert  channels. 


4.1  Documenting  The  Security  Policy 

The  design  and  development  of  any  trusted  system,  from  TCSEC  class  Cl  to 
Al,  is  based  upon  a  philosophy  of  protection  that  shall  be  described  in  the  design 
documentation  (Requirement  1).  Design  documentation  explains  and  defines  the 
philosophy  of  protection  by  describing  how  a  system  provides  trust.  Trust  in 
computer  systems  is  provided  by  the  protection  mechanisms  contained  within  the 
TCB,  such  as  discretionary  access  controls  and  identification  and  authentication 
mechanisms.  These  and  all  of  the  TCB  mechanisms  and  their  functions  shall  be 
described  in  the  design  documentation.  In  addition,  the  system  security  policy,  i.e., 
what  is  being  accessed  by  whom  or  from  what,  shall  also  be  described  in  the  design 
documentation  (Requirement  6). 

In  order  to  describe  how  a  system  is  trustworthy,  the  design  documentation 
shall  describe  how  the  philosophy  of  protection  is  translated  into,  the  TCB 
(Requirement  2)  and  how  it  is  supported  by  the  TCB  protection  mechanisms.  The 
design  documentation  shall  first  define  the  boundaries  of  the  system  and  shall 
describe  the  parts  of  the  system  that  are  security  relevant  and  the  parts  that  are  not. 
Rationale  shall  be  presented  that  those  portions  of  the  system  which  are  claimed  to 
be  outside  of  the  TCB,  are  really  outside.  The  proper  identification  of  these  parts  is 
important  to  the  maintenance  of  security  in  the  system  because  it  is  necessary  to 
know  when  a  change  to  the  system  will  affect  the  TCB  implementation,  and  possibly 
violate  the  security  policy  of  the  system. 

At  the  higher  TCSEC  classes,  the  description  of  the  philosophy  of  protection 
evolves  into  a  more  structured  description  of  how  a  system  provides  trust.  At  TCSEC 
class  Bl,  this  philosophy  of  protection  shall  be  presented  as  an  informal  or  formal 
security  policy  model  in  the  design  documentation  (Requirement  7).  This  security 
policy  model  shall  informally  or  formally  define  the  subjects,  objects,  modes  of  access, 
and  the  security  properties  of  the  system.  In  addition,  the  model  shall  define  the 
initial  state  of  the  system,  a  secure  state  of  the  system,  and  the  way  in  which  the 
system  progresses  from  one  state  to  the  next.  An  informal  security  policy  model  may 
be  presented  in  a  natural  language,  for  example,  English.  An  explanation  shall  be 
provided  demonstrating  that  the  informal  model  is  sufficient  to  enforce  the  security 
policy  (Requirement  8). 
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At  TCSEC  class  B2,  a  formal  security  policy  model  shall  exist  (Requirement 
13).  In  addition  to  the  B1  requirements,  the  formal  security  policy  model  shall 
contain:  a  set  of  security  properties  that  captures  the  security  policy,  an  abstract 
description  of  the  operations  performed  by  the  TCB,  and  a  rigorous  argument 
through  the  use  of  predicate  calculus  that  the  description  is  consistent  -  internally 
consistent,  that  is,  is  not  self-contradictory.  The  model  shall  include  a  proof  that  if 
the  initial  state  of  the  system  satisfies  the  definition  of  a  "secure”  state  and  if  all 
assumptions  of  the  model  are  satisfied,  then  all  future  states  of  the  system  will  be 
secure. 

A  security  policy  model  provides  assurance  that  the  system  has  been  designed 
to  enforce  the  security  policy  and  provides  a  basis  for  the  TCB  implementation.  As  a 
means  of  increasing  assurance,  the  design  documentation  shall  show  that  the 
security  policy  model  is  sufficient  to  enforce  the  security  policy  of  the  system 
(Requirement  8).  At  TCSEC  class  Bl,  it  shall  be  sufficient  to  show  this  in  a  natural 
language,  e.g.,  English,  but  at  class  B2,  this  sufficiency  of  the  security  policy  model 
shall  be  shown  through  a  formal  proof  (Requirement  14).  The  design  documentation 
shall  provide  a  mapping  of  the  security  properties  to  the  security  policy.  This 
sufficiency  shall  be  demonstrated  by  describing  how  all  aspects  of  the  security  policy 
are  addressed  by  the  security  policy  model. 

An  example  of  a  formal  security  policy  that  enforces  the  DoD  security  policy  is 
the  Bell-La  Padula  model  [1].  Although  the  Bell-La  Padula  security  policy  model 
supports  the  DoD  security  policy,  it  is  important  to  realize  that  this  does  not  mean 
that  the  Bell-La  Padula  model  model  can  be  directly  used  for  all  systems.  The  Bell- 
La  Padula  model,  when  used  with  different  systems,  will  need  to  be  representative  of 
the  system. 

At  TCSEC  class  B2,  the  TCSEC  design  specification  and  verification 
requirement  calls  for  a  descriptive  top  level  specification  (DTLS)  of  the  TCB  to  be 
maintained  to  provide  documentary  evidence  of  how  the  formal  security  policy  model 
is  implemented  through  the  TCB  interface.  The  DTLS  provides  evaluators  with  a 
better  understanding  of  the  implementation  of  the  reference  monitor  and  provides 
maintenance  personnel  with  the  necessary  documentation  to  correct,  modify,  or 
augment  the  TCB  without  destroying  the  TCB’s  cohesiveness  and  internal 
consistency.  The  description  of  the  TCB  should  contain  a  description  of  the  services 
and  functions  provided  by  the  TCB  and  how  they  are  invoked.  For  example,  for 
UNIX^based  systems,  the  DTLS  may  be  based  upon  enhanced  manual  pages.  The 
manual  pages  shall  include  enough  information  to  satisfy  the  design  specification 
and  verification  requirement  that  the  TCB  be  described  in  "terms  of  exceptions, 
error  messages,  and  effects. ”[5]  These  individual  manual  sections,  should  be 
accompanied  by  detailed  section  headers  which  clearly  explain  the  security  concepts 
and  entities  referenced  within  each  section.  The  design  documentation  shall 
demonstrate  that  the  DTLS  is  an  accurate  description  of  the  TCB  interface 
(Requirement  15).  It  should  do  this  by  accurately  and  completely  describing  the 
DTLS  in  relation  to  the  TCB  interface. 

The  design  documentation  shall  be  used  to  test  against  the.  TCB  to, 
"demonstrate  that  the  TCB  implementation  is  consistent  with  the  descriptive  top 
level  specification.”  [5]  The  design  documentation  shall  describe  how  the  TCB  is 
structured  to  facilitate  this  testing  (Requirement  20). 


1  UNIX  is  a  trademark  of  AT&T  Bell  Labs 
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At  TCSEC  class  B3,  the  design  documentation  shall  informally  show 
consistency  of  the  TCB  hardware,  firmware,  and  software  implementation  with  the 
DTLS  as  well  as  showing  correspondence  between  elements  of  the  DTLS  and 
elements  of  the  TCB  (Requirements  29,  30).  The  goal  of  these  two  requirements  is  to 
ensure  that  the  mapping  between  the  TCB  and  DTLS  is  complete,  easily 
understandable,  unambiguous,  and  one-to-one  between  elements  of  the  TCB 
implementation  and  elements  of  the  DTLS.  The  level  of  detail  of  this  mapping 
should  be  sufficient  for  any  inconsistency  to  be  obvious  to  members  of  the  vendor's 
development  team  throughout  the  system  life-cycle. 

Also  at  TCSEC  class  B3,  the  design  documentation  shall  provide  a  mapping 
from  the  DTLS  to  the  TCB  implementation  (Requirement  30).  This  mapping  should 
demonstrate  that  all  elements  that  were  specified  were,  in  fact,  implemented,  and 
that  any  code  that  appears  which  is  not  specified  directly  merely  reflects 
implementation  detail;  that  there  are  no  new,  unspecified,  user  interfaces 
implemented.  With  this  mapping,  the  design  documentation  shall  describe  all  areas 
of  correspondence  between  elements  of  the  DTLS  and  elements  of  the  TCB.  For 
example,  the  mapping  may  be  pointers  in  the  DTLS  description  to  source  code 
modules  of  the  TCB  implementation. 

The  addition  of  the  design  specification  and  verification  requirement  of  a 
mapping  between  the  DTLS  and  the  formal  security  policy  model  completes  the 
evidence  from  the  security  policy  to  implementation.  The  entities  of  the  model  shall 
be  shown  to  correspond  to  the  elements  of  the  DTLS  (Requirement  31).  This 
correspondence  provides  assurance  that  the  security  properties  that  are  proven  in 
the  formal  model  are  accurately  reflected  in  the  implementation. 

At  TCSEC  class  Al,  the  mapping  shall  be  from  the  formal  top  level 
specification  (FTLS)  to  the  TCB  (Requirements  32,  33).  In  addition,  the  mapping  to 
the  model  shall  be  from  the  FTLS  (Requirement  35).  These  changes  reflect  the 
introduction  of  an  FTLS  requirement  in  the  design  specification  and  verification 
requirements  at  Al.  The  design  documentation  shall  describe  how  the  FTLS 
accurately  represents  the  TCB  interface.  The  hardware/firmware  components  of  the 
TCB,  such  as  mapping  registers  and  direct  memory  access  input/output  (I/O) 
components,  that  are  directly  or  indirectly  visible  at  the  TCB  interface  shall  be 
described  in  the  design  documentation.  As  stated  previously,  the  goal  of  these 
requirements  is  to  ensure  that  the  mapping  between  the  elements  of  the  TCB 
implementation  and  the  FTLS  are  complete,  easily  understandable,  unambiguous, 
and  one-to-one. 

Although  the  TCSEC  design  documentation  requirement  changes  at  class  Al 
to  require  a  mapping  from  the  FTLS  to  the  TCB,  a  DTLS  is  still  required  for  class  Al 
systems.  At  TCSEC  class  Al,  the  DTLS  serves  to  augment  the  FTLS  by  completing 
the  description  of  the  TCB  in  an  informal  language  and  by  providing  the  conceptual 
glue  to  the  specification  of  the  reference  monitor  mechanism  and  the  other  TCB 
components.  Since  there  is  an  explicit  requirement  at  class  Al  that  both  the  FTLS 
and  DTLS  correspond  to  the  formal  security  policy  model,  the  DTLS  and  the  FTLS 
must  correspond  (Requirement  36).  At  TCSEC  class  Al,  "the  FTLS  and  DTLS  may 
be  two  separate  documents,  or  they  may  be  combined  into  a  Complete  Top  Level 
Specification  (CTLS).  In  a  CTLS,  the  FTLS  and  DTLS  portions  (shall)  be  separately 
identifiable.  The  CTLS  (shall)  be  a  complete  and  accurate  description  of  the  TCB, 
and  it  (shall)  be  sufficiently  well  commented/annotated,  so  that  it  can  be  easily 
understood  with  little  or  no  knowledge  of  formal  specifications.”!^] 
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It  is  recognized  that  not  all  of  the  TCB  internals  are  able  to  be  specified  within 
the  FTLS.  For  the  hardware,  firmware,  and  software  internal  to  the  TCB,  but  not 
dealt  with  in  the  FTLS,  the  design  documentation  shall  describe  them  in  complete, 
clear,  and  careful  detail  (Requirement  34). 


4.2  Documenting  TCB  Protection  Mechanisms 

As  part  of  the  description  of  the  philosophy  of  protection  and  how  it  translates 
into  the  TCB,  the  design  documentation  shall  include  explanations  of  the  security 
services  offered  by  the  TCB  software,  hardware,  and  firmware  mechanisms  from  a 
system  level  view  (Requirement  2).  At  TCSEC  class  Cl,  the  design  documentation 
for  these  protection  mechanisms  shall  include  how  the  mechanisms  protect  the  TCB 
from  tampering  (Requirements  5).  The  description  of  why  the  TCB  is  tamper 
resistant  is  an  important  requirement  for  all  of  the  TCSEC  classes.  This  design 
documentation  requirement  supports  the  TCSEC  class  Cl  system  architecture 
requirement  which  calls  for  the  TCB  to  maintain  a  domain  that  implements  the 
reference  monitor  concept  that,  "protects  it  from  external  interference  or 
tampering”[5].  The  mechanisms  described  in  this  section  of  the  design 
documentation  include  things  such  as  Discretionary  Access  Control  (DAC)  and 
identification  and  authentication  (I&A)  mechanisms.  For  example,  the  design 
documentation  shall  describe  the  DAC  enforcement  mechanism  and  how  it  controls 
discretionary  access  between  named  users  or  groups  and  named  objects  within  the 
ADP  system.  As  it  relates  to  identification  and  authentication,  the  design 
documentation  shall  describe  how  users  are  identified  to  the  TCB  and  the 
mechanism  that  authenticates  the  user's  identity.  Furthermore,  the  design 
documentation  shall  describe  how  the  TCB  protects  the  authentication  data.  To 
ensure  that  these  mechanisms  have  not  failed  in  any  way,  hardware  and  software 
mechanisms  shall  exist  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB.  These  system  integrity  mechanisms 
shall  also  be  described  in  the  design  documentation. 

At  TCSEC  class  Bl,  the  design  documentation  shall  identify  and  provide 
descriptions  of  the  TCB  protection  mechanisms  (Requirement  9).  This 
documentation  is  required  to  provide  the  additional  assurance  required  at  TCSEC 
class  Bl.  In  most  cases,  these  TCB  protection  mechanisms  at  TCSEC  class  Bl  may 
be  the  same  protection  mechanisms  that  were  described  in  TCSEC  class  Cl,  but  at 
class  Bl,  the  description  of  these  mechanisms  shall  describe  how  they  support  the 
additional  system  architecture  requirement  for  process  isolation.  Process  isolation 
mechanisms  that  prevent  untrusted  subjects  from  directly  accessing  separate 
address  spaces  are  introduced  at  TCSEC  class  Bl  and  shall  be  described  in  the  design 
documentation.  The  design  documentation  shall  also  show  that  all  of  the  security 
services  required  by  the  security  policy  model  are  provided  by  the  TCB  mechanisms 
(Requirement  10). 
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At  TCSEC  class  B2,  the  design  documentation  shall  describe  how  the  TCB 
protection  mechanisms  implement  the  reference  monitor  concept,  i.e.,  is 
nonbypassable,  always  invoked,  and  small  enough  to  be  analyzed  (Requirement  16). 
The  design  documentation  requirement  should  demonstrate  how  the  reference 
validation  mechanism  is  tamper  resistant,  cannot  be  bypassed,  is  correctly 
implemented,  and  is  structured  to  enforce  least  privilege  (Requirements  17,  18,  19, 
21)  Although  a  reference  monitor  has  been  in  place  since  TCSEC  class  Cl,  the 
system  architecture  requirements  at  TCSEC  class  B2  require  that  the  TCB  be 
protected,  "from  external  interference  and  tampering,”  maintain  process  isolation 
and  be  "internally  structured  into  well  defined  largely  independent  modules.  [5] 
These  additional  requirements  shall  be  reflected  in  the  design  documentation. 


One  position  for  how  the  reference  monitor  hardware  should  be  documented  is 
presented  in  the  following  paragraphs: 


"For  microprograms  (firmware),  design  documentation  is  needed  for  common 
routines  that  is,  documentation  which  fully  describes  the  functionality  and  what  is 
done  to  implement  that  functionality.  At  the  least,  a  high  level  view  of  major 
operations,  e.g.,  interrupts,  I/O  instruction  interpretations  is  needed  if  the  microcode 

is  yir.t  modula:'  r.oough  to  fee  described  i  a  W<  -os  of  .nicroroutines. 


-/or  it  eras  ’nsHe  th  TCB.  'i.e  it 
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In  the  case  of  systems  that,  do  not  use  microcode,  convincing  arguments  must 
vided  as  to  what  elements  of  the  hardware  are  security  critical  and  wfey."[2] 


The  design  documentation  for  li:- 

documentation  that  is  written  for  the  TuB 
the  functionality  and  what  is  done  to  imp 


e  TCB  firmware  should  parallel  the 
sort  ware,  that  is,  it  should  fully  describe 
lement  the  functionality  of  the  security 


kernel. 


Assurance  needs  to  be  provided  that  the  TCB  is  protected  from  modification. 
At  TCSEC  class  B2,  the  design  documentation  shall  provide  this  assurance  through 
a  description  of  why  the  reference  monitor  is  tamper  resistant  (Requirement  17). 
This  description  shall  include  the  methods  and  mechanisms  by  which  the  TCB 
protects  itself  from  illicit  modification.  Any  hardware  mechanisms  used  by  the  TCB 
to  separate  protection  critical  elements  from  those  that  are  not  protection  critical 
shall  be  described.  The  mechanisms  used  by  the  TCB  to  help  support  logically 
distinct  storage  objects  with  separate  attributes  shall  also  be  described.  The 
mechanisms  used  to  protect  against  illicit  modification  may  include  some  of  the 
same  mechanisms  used  to  mediate  accesses  of  objects  by  subjects  that  were 
introduced  at  TCSEC  class  Cl.  These  mechanisms  shall  be  described  again  at 
TCSEC  class  B2,  but  in  greater  detail  as  to  how  they  apply  to  the  reference 
validation  mechanism. 
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The  previous  paragraph  explained  how  the  design  documentation  describes 
protection  mechanisms,  but  more  importantly,  at  TCSEC  class  B2,  the  design 
documentation  shall  show  that  all  of  the  TCB  software,  firmware,  and  hardware 
mechanisms  have  been  implemented  as  described  and  that  the  implementation 
functions  correctly  (Requirement  19).  The  design  documentation  shall  justify  the 
correctness  of  the  entire  TCB. 

Also,  at  TCSEC  class  B2,  the  design  documentation  shall  describe  how  the 
TCB  is  structured  to  enforce  least  privilege  (Requirement  21).  This  description  shall 
relate  to  the  hardware,  firmware,  and  software  modules  of  the  TCB,  as  well  as  to  the 
enforcement  of  least  privilege  both  within  the  TCB  and  upon  trusted  subjects.  Least 
privilege  ensures  that  any  TCB  module  or  trusted  process  has  only  those  privileges 
and  capabilities  needed  for  it  to  perform  the  specific  function  for  which  it  was 
designed.  For  example,  if  the  hardware  architecture  implements  protection  rings,  a 
description  shall  be  given  of  the  ring  mechanisms.  This  description  shall  show  how 
access  to  the  innermost  ring  provides  a  means  of  running  highly  privileged 
processes,  while  the  outermost  ring  provides  a  means  of  running  unprivileged 
processes.  Likewise,  the  description  shall  justify  placement  of  functions  within  the 
higher  privileged  rings  and  the  conferring  of  special  privileges  to  trusted  processes. 
Thus,  the  hardware  is  shown  as  a  means  of  enforcing  least  privilege. 

Similarly,  firmware  and  software  mechanisms  may  provide  a  means  of 
enforcing  least  privilege.  For  example,  a  labeling  mechanism  may  be  implemented 
in  software  or  firmware.  Because  labels  may  be  used  to  enforce  least  privilege,  the 
software  or  firmware  modules  enforcing  the  labeling  and  label  based  access  control 
shall  be  shown  as  a  means  of  enforcing  least  privilege. 

The  separation  of  administrative  roles  in  the  system  is  one  more  way  in  which 
least  privilege  may  be  exercised.  In  this  case,  the  roles  of  system  administrator, 
security  administrator,  and/or  system  auditor  may  be  performed  by  separate 
individuals.  This  is  to  ensure  that  the  security  functions  of  the  system  are  not  able  to 
be  performed  by  a  single  person.  The  way  these  roles  are  carried  out  in  the  system 
shall  be  described  in  the  design  documentation. 

At  TCSEC  class  B3,  the  system  architecture  requirements  call  for  the  TCB  to 
be  minimized,  i.e.,  only  security  relevant  functions  appear  within  the  TCB.  The  TCB 
at  this  class,  "shall  incorporate  significant  use  of  layering,  abstraction,  and  data 
hiding,”  and  shall  have  minimal  complexity.  The  design  documentation  shall 
describe  how  the  system  complies  with  these  additional  architectural  requirements 
in  (Requirement  28).  As  stated  previously,  as  the  TCSEC  classes  increase  and  the 
implementation  of  the  reference  monitor  concept  becomes  more  defined,  the  amount 
of  design  documentation  shall  also  increase. 

4.3  Documentation  of  Covert  Channels 

A  portion  of  the  B2  requirements  for  design  documentation  addresses  covert 
channels.  The  results  of  all  covert  channel  analysis  need  to  be  in  the  design 
documentation  to  aid  in  the  design  and  development  of  TCB  mechanisms.  For  this 
reason,  the  design  documentation  shall  present  the  results  of  the  covert  channel 
analysis  and  the  methodology  used  (Requirement  22).  The  design  documentation 
shall  provide  an  overview  of  the  covert  storage  channel  analysis  and  testing 
procedures.  It  shall  document  the  results  of  these  tests  and  all  of  the  covert  channels 
identified.  All  auditable  events  shall  be  identified  and  described  for  all  covert 
storage  channels  that  are  not  removed  from  the  system  (Requirement  24). 
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When  covert  channels  are  identified,  actions  are  sometimes  taken  to  restrict 
the  bandwidth  of  those  channels.  The  design  documentation  shall  describe  and 
discuss  these  actions  and  the  resulting  degree  of  covert  channel  restriction  in  light  of 
performance  degradation,  operational  utility,  or  other  considerations  (Requirement 
23).  Processing  delays  resulting  from  reducing  the  number  and  bandwidth  of  covert 
channels  shall  be  identified  and  characterized.  The  design  documentation  shall  also 
note  whether  the  exploitation  of  known  covert  channels  is  auditable.  There  will  be 
some  covert  storage  channels  whose  use  will  not  be  detectable  by  auditing 
mechanisms.  The  design  documentation  shall  document  the  worst  case  and  expected 
case  bandwidths  of  these  storage  channels  whose  exploitation  is  not  auditable 
(Requirement  25). 

At  TCSEC  class  B3,  the  design  documentation  shall  recognize  the 
introduction  of  covert  timing  channels  into  the  requirements  and  shall  consider 
them  in  all  covert  channel  related  descriptions  as  stated  above  (Requirements  26, 
27).  The  covert  timing  channel  analysis  and  testing  procedures,  and  the  results 
obtained  from  the  tests  shall  be  described  in  the  design  documentation.  Additionally 
at  TCSEC  class  Al,  formal  methods  shall  be  used  in  the  covert  channel  analysis  and 
shall  be  described  in  the  design  documentation. 
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5.  OTHER  TOPICS 


5.1  Modularity 

An  important  architectural  feature  of  trusted  systems  for  TCSEC  class  B2  and 
above  is  that  the  TCB  be  modular.  The  modularity  of  the  TCB  is  important  for  ease 
of  understanding,  ease  of  analysis,  and  ease  of  maintenance.  Modularity  ensures 
that  interfaces  are  well  defined  and  errors  are  contained.  It  also  provides  a  basis  for 
enforcing  least  privilege.  The  content  of  hardware  and  software  modules  should  be 
selected  based  on  the  following  criteria:  a  module  performs  exactly  one  well  defined 
action,  a  module  has  a  well  defined  interface,  a  module  interacts  with  other  modules 
only  in  well  defined  ways,  and  a  module  is  called  upon  to  perform  a  function 
whenever  that  function  is  required.  Although  TCB  modularity  is  not  a  requirement 
until  class  B2  (Requirements  11,  12),  it  is  possible  that  vendors  would  want  to  build 
systems  with  modular  TCBs  at  the  lower  classes.  Regardless  of  class,  if  the  TCB  is 
modular,  the  design  documentation  shall  describe  how  the  TCB  is  modular  and  the 
interfaces  between  the  TCB  modules  (Requirement  3,  4).  As  with  all  design 
documentation,  the  level  of  detail  shall  permit  the  description  of  the  interfaces 
between  the  modules  to  be  a  useful  description.  Specifically,  the  design 
documentation  shall  include  identification  of  the  TCB  hardware,  software,  and 
firmware  modules,  why  the  modules  are  considered  as  such,  the  interfaces  between 
them,  and  the  implementation  of  the  modules.  A  mapping  of  the  security  services 
and  mechanisms  to  the  modules  should  also  be  described. 

The  level  of  detail  of  the  design  documentation  increases  the  amount  of 
assurance  to  be  gained  by  the  developers  and  evaluators.  The  description  of  the 
interfaces  between  the  modules,  whether  hardware,  firmware,  or  software,  shall 
describe  the  types  and  sources  of  information  passing  between  them  (Requirement 
4).  In  addition,  the  interfaces  between  these  TCB  modules  and  other  system  modules 
external  to  the  TCB  shall  be  described.  This  description  is  necessary  to  show  that  no 
breach  of  security  can  occur  through  the  interfaces. 

In  some  cases,  software  modules  may  depend  upon  hardware  or  firmware 
modules  to  perform  correctly  and  these  dependencies  should  also  be  included  in  the 
design  documentation. 


5.2  Hardware  Design  Documentation 

Hardware  design  documentation  for  a  system  shall  be  provided  at  all  levels  of 
trust.  Specifically,  at  TCSEC  classes  B2  and  above,  it  is  felt  that  the  hardware 
design  documentation  is  critical  to  the  security  of  a  system.  At  this  class,  systems 
"shall  make  effective  use  of  available  hardware  to  separate  those  elements  that  are 
protection  critical  from  those  that  are  not.”[5]  To  meet  this  TCSEC  requirement, 
developers  should  know  the  hardware  base  they  are  building  on  top  of.  Also, 
evaluators  will  need  the  hardware  design  documentation  in  order  to  evaluate  that 
the  vendor  is  making  "effective  use”  of  the  hardware. 
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The  hardware  design  documentation  includes  descriptive  information  about 
the  system's  Central  Processing  Unit(s)  (CPU),  Memory  Management  Unit(s) 
(MMU),  and  all  other  additional  processors,  for  example,  I/O  Processors,  channel 
devices.  The  hardware  design  documentation  is  intended  to  discuss  what  the 
hardware  is  meant  to  do,  but  does  not  need  to  include  details  of  implementation,  such 
as  the  flow  of  control  to  perform  a  specific  action.  The  hardware  design 
documentation  for  every  logical  module  in  the  hardware  base  should  include  a 
functional  name,  functional  description,  and  a  functional  interface  of  that  module. 

The  hardware  design  documentation  defines  the  hardware  portion  of  the  TCB 
interface.  The  information  on  the  hardware  interface  is  important  to  correctly 
develop  TCB  routines  and  device  drivers.  Additionally,  the  hardware  design 
documentation  provides  sufficient  information  that  the  TCB  meets  the  System 
Architecture  requirements  of  the  TCSEC. 

The  information  contained  in  the  hardware  design  documentation  shall  be 
complete,  specifying  all  possible  interfaces  to  the  system  hardware,  including  the 
user-to-hardware  interface  as  well  as  the  TCB  software-to-hardware  interface.  The 
hardware  design  documentation  should  include  unprivileged  instructions,  privileged 
instructions,  unpublished  instructions,  and  all  CPU-to-MMU,  CPU-to-Channel, 
CPU-to-I/O  bus,  and  additional  processor  interactions.  Also,  the  software  interface 
visible  registers  that  exist  on  the  CPU,  MMU,  and  other  processors  shall  be 
described  in  the  hardware  design  documentation. 

The  design  documentation  for  some  hardware  modules  may  require  internal 
detail  down  to  a  bit  level  functional  description  of  the  module.  The  modules  that  fall 
into  this  category  are  those  that  make  up  the  reference  monitor,  such  as  the  address 
translation  module,  process  isolation  support  module,  fault  handling  module,  I/O 
control  module,  and  the  diagnostic  module.  These  hardware  modules  of  the 
reference  monitor  directly  support  security  and  will  require  an  explanation  of  why 
the  reference  monitor  is  "tamper  resistant,  cannot  be  bypassed,  and  is  correctly 
implemented. ”[5] 


5.3  Configuration  Management 

The  design  documentation  for  the  system  shall  be  under  configuration 
management  for  the  entire  life-cycle  of  the  system.  Design  documentation  is  only 
useful  if  it  is  complete  and  accurate.  This  means  that  any  change  to  the  system 
should  also  result  in  a  change  to  the  design  documentation  for  the  system. 

The  design  documentation  for  a  system  should  be  treated  as  a  configuration 
item  for  the  system  and  should  be  subject  to  the  identification,  control,  accounting, 
and  audit  functions  of  configuration  management.  "Initial  phases  of  configuration 
control  are  directed  towards  control  of  the  system  configuration  as  defined  primarily 
in  design  documents.  Often  a  change  to  one  area  of  a  system  may  necessitate  a 
change  to  anothejr  area.  It  is  not  acceptable  to  only  write  documentation  for  new  code 
or  newly  modified  code,  but  rather  documentation  for  all  parts  of  the  TCB  that  were 
affected  by  the  addition  or  change  shall  be  updated  accordingly.  Although 
documentation  may  be  available,  unless  it  is  kept  under  configuration  management 
and  updated  properly  it  will  be  of  little,  if  any  use.  In  the  event  that  the  system  is 
found  to  be  deficient  in  documentation,  efforts  should  be  made  to  create  new 
documentation  for  areas  of  the  system  where  it  is  presently  inadequate  or 
nonexistent."[7] 
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The  TCSEC  requirements  for  configuration  management  do  not  begin  until 
TCSEC  class  B2,  but  this  should  not  mean  that  the  design  documentation  tor  i  CbEb 
class  Cl  to  B1  systems  not  be  under  some  type  of  control.  At  these  lower  classes,  the 
control  process  for  the  design  documentation  may  be  less  formal  than  that  required 
by  the  configuration  management  requirements,  but  it  should  still  provide 
assurance  that  the  design  documentation  accurately  describes  the  current  system. 

The  National  Computer  Security  Center  has  recently  developed  the  Ratings 
Maintenance  Program  (RAMP)  which  requires  configuration  management  at  these 
lower  classes  of  trust.  "By  training  vendor  personnel  to  recognize  which  changes 
may  adversely  affect  the  implementation  of  the  security  policy  of  the  system,  and  to 
track  these  changes  to  the  evaluated  product  through  the  use  of  configuration 
management,  RAMP  will  permit  a  vendor  to  maintain  the  rating  of  the  evaluated 
product  without  having  to  reevaluate  the  new  version."  [7] 

For  further  information  about  the  RAMP  program  and  about  the 
configuration  management  requirements  for  RAMP,  contact. 

National  Computer  Security  Center 

9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755  6000 


Attention:  C12 
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6.  SUMMARY  OF  DESIG  V  DOCUMENTATION 

Desien  documentation  is  responsible  for  describing  systems  at  all  levels  of  trust. 
During  the  life-cyde  of  a  system,  it  describes  the  system  to  facilitate  changes  and 
maintenance  of  the  system  As  it  relates  to  the  security  of  a  system,  design 
documentation  provides  assurance  by  describing  how  a  system  provides  trust  and 
shows  that  all  of  the  protection  mechanisms  of  a  syst. em  ar e  corr ect  y  ™Ple”«  ‘ 
sufficiently  provide  the  needed  trust.  At  the  lower  classes,  aeoigx 

documentation  begins  to  describe  how  security  is  bytjfe  ^elign 

philosophy  of  protection  of  the  system.  At  TCSEC _  class i  Bl,  tne  oesig 
documentation  describes  the  security  policy  model  of  a  system,  and  at  TCSEC  class 
B2  the  security  policy  model  is  required  to  be  formal. 

Manv  of  the  other  requirements  in  the  TCSEC  are  related  to  design 
documentation  Design  documentation  shall  describe  how  these  requirements  are 
satisfied  Covert  channels  are  specifically  addressed  m  the  desxgn  documentation 
requirement  The  assurance  provided  by  design  documentation  is  dependent  upon 
iktwLhness  and  accuracy  When  design  documentation  is  written,  the  role  that 
it^lay^irfth^systemHfe-^^e  should  be  kept  in  mind.  A  new  employee  shoud  be 
able  to  look  at  the  design  documentation  and  get  an  understanding  of  what  the 
current  system  is  and  how  it  works.  The  key  word  in  design  documentation  is 
current.  When  a  system  changer,  the  design  documentation  shall  chang 
accordingly  By  accurately  describing  a  system,  design  documentation  prov 
assurance  that  there  is  an  understanding  of  how  and  why  the  system  provides  trust. 
InS^dUtonfit  provides  information  tha/will  enable  developers  to ja^^es  to 
the  system  to  ensure  that  they  do  not  adversely  affect  the  trustworthiness 

system. 
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SUMMARY  OF  DESIGN  DOCUMENTATION  REQUIREMENTS 
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SUMMARY  OF  DESIGN  DOCUMENTATION  REQUIREMENTS 
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SUMMARY  OF  DESIGN  DOCUMENTATION  REQUIREMENTS 
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APPENDIX  B 


EXCERPTS  FROM  FINAL  EVALUATION  REPORTS 


This  appendix  reproduces  excerpts  from  Final  Evaluation  Reports  for  products 
currently  on  the  Evaluated  Products  List.  The  excerpts  are  reproduced  from  the 
"Applicable  Features"  portion  of  the  section  describing  how  the  product  met  the 
requirements  for  Design  Documentation. 

The  Final  Evaluation  Reports  are  available  from  the  National  Computer 
Security  Center.  However,  most  of  the  vendor  documents  mentioned  in  this 
appendix  contain  proprietary  information,  and  therefore  are  not  publicly  available. 
Please  do  not  request  copies  of  the  vendor  documents  from  the  National  Computer 
Security  Center. 


B.l  CLASS  C2 

B.1.1  UTX/32S  [6] 

The  following  documents  were  provided  to  the  evaluation  team  in  fulfillment 
of  the  Design  Documentation  criterion: 

"Security  Policy  Model" 

"Program  Maintenance  Manual  UTX/32S,  Release  1.0  (DRAFT)  . 

"System  Calls”  and  "Maintenance"  in  the  "System  Administrator's 

Reference  Manual". 

"4.2BSD  and  UTX-32  Differences  Study  for  Gould  UTX/32S" 

"Memory  Management  for  Gould  UTX/32S" 

"Object  Reuse  Study  for  Gould  UTX/32S" 

The  "Gould  UTX/32S  1.0  Security  Policy  Model"  describes  Gould's  philosophy 
of  protection  and  explains  how  this  philosophy  is  translated  into  the  TCB.  It 
identifies  all  elements  comprising  the  TCB,  including  the  kernel,  programs,  data 
files,  and  processes.  Subjects  and  objects  are  identified,  and  the  mediation  of 
accesses  between  them  is  described.  A  mapping  from  the  TCB  to  the  security 
philosophy  is  provided,  and  the  discretionary  access  control,  identification  and 
authentication,  and  audit  features  and  mechanisms  are  described.  Additionally,  the 
document  discusses  the  role  of  secure  sockets  in  interprocess  communications.  The 
"Gould  UTX/32S  1.0  Security  Policy  Model"  identifies  all  programs  comprising  the 
TCB. 


The  kernel  interface  is  described  by  the  "System  Calls"  section  of  the  "System 
Administrator's  Reference  Manual".  The  "Maintenance"  section  of  the  reference 
manual  comprises  manual  pages  useful  for  systems  programmers  in  maintaining 
UTX/32S.  "4.2BSD  and  UTX-32  Differences  Study  for  Gould  UTX/32S"  describes 
differences  between  4.2BSD  UNIX  and  Gould  UTX/32  1.2.  Using  "4.2BSD  and 
4.3BSD  as  Examples  of  the  UNIX  System,"  by  J.S.  Quarterman,  A.  Silberschatz, 
and  J.L.  Peterson  (Computing  Surveys,  Vol.  17,  No.  4,  December  1985,  pp.  379-418), 
as  a  baseline,  the  document  identifies  all  instances  where  Gould  UTX/32  differs 
from  the  described  UNIX  system. 
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The  "UTX/32S  Program  Maintenance  Manual"  describes  code  modifications 
made  to  UTX/32  to  meet  the  requirements  of  the  "Gould  UTX/32S  1.0  Security 
Policy  Model".  The  document  includes  an  overview  of  the  mechanisms  implemented 
in  UTX/32S  to  strengthen  security  and  to  correct  problems  found  in  UTX/32  and 
other  UNIX  systems,  and  detailed  descriptions  for:  the  implementation  of  trusted 
servers  to  replace  the  functionality  of  the  eliminated  setuid  and  setgid  bits;  kernel 
modifications;  auditing  mechanisms;  and  additions,  deletions,  and  modifications  to 
utilities  and  libraries.  Each  module  description  includes  an  overview,  a  functional 
specification,  and  a  design  specification.  Pointers  to  source  code,  which  Gould  made 
available  to  the  evaluation  team  are  provided. 

Security  critical  features  of  the  Gould  PowerNode  hardware  used  by  UTX/32S 
are  described  in  "UTX/32S  Traps  and  Interrupts  and  Memory  Management  for 
Gould  UTX/32S."  "UTX/32S  Traps  and  Interrupts"  describes  how  UTX/32S  makes 
use  of  the  trap  and  interrupt  facilities  to  interface  with  the  hardware  and  process 
environments.  "Memory  Management  for  Gould  UTX/32S"  describes  how  UTX/32S 
uses  the  memory  management  facilities  of  the  PowerNode  hardware  to  provide  the 
process  environment.  Both  documents  include  applicable  material  from  "Gould  SS  6 
(Virtual  Mode),  V6,  and  V9  Central  Processing  Unit  Reference  Manual". 

"Object  Reuse  Study  for  Gould  UTX/32S"  provides  details  regarding  how 
UTX/32S  hardware  and  software  manage  system  objects.  This  study  identifies  the 
system  resources  which  can  be  allocated  and  deallocated,  and  details  the  strategies 
used  to  ensure  that  one  process  cannot  gain  access  to  the  resources  or  data  previously 
allocated  to  another  process.  This  study,  along  with  "Memory  Management  for 
Gould  UTX/32S",  provides  a  good  description  of  UTX/32S  design  features  which  are 
used  to  meet  the  Object  Reuse  criterion. 


B.2  CLASS  B2 

B.2.1  Multics  [3] 

The  following  documents  satisfy  the  Design  Documentation  requirement: 
Applicable  Features 

The  "Computer  Security  Model:  Unified  Exposition  and  MULTICS 
Interpretation"  provides  a  description  of  Honeywell's  philosophy  for 
protection  and  how  this  is  translated  into  the  TCB.  The  security  model 
enforced  by  the  TCB  is  the  Bell-La  Padula  model. 

Multics  has  a  set  of  Multics  Design  Documents  (MDDs)  that  describe  the  TCB. 
(These  documents  are  Honeywell  Internal  Documentation  and  are  available  only 
through  the  vendor  by  request.  Honeywell  reserves  the  right  to  deny  such  requests.) 
The  MDDs  are  organized  by  major  TCB  service  or  function.  These  design  documents 
describe  the  interfaces  between  TCB  modules,  how  the  TCB  implements  the 
reference  monitor,  and  how  the  TCB  is  structured  to  facilitate  testing  and  enforce 
least  privilege. 

These  documents  coupled  with  the  Honeywell  produced  "Multics 
Interpretation,"  referenced  in  the  previous  paragraph  identify  the  security 
protection  mechanisms  and  explain  how  they  satisfy  the  model. 
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The  DTLS  is  an  accurate  description  of  the  TCB  interface.  The  Covert 
Channel  Analysis"  describes  all  identified  covert  channels,  how  they  can  and  cannot 
be  restricted,  how  they  are  audited,  and  their  bandwidths. 


B.3  CLASS  A1 

B.3.1  SCOMP  [4] 

The  following  documents  satisfy  the  Design  Documentation  requirement: 

The  manufacturer’s  philosophy  of  protection  is  documented  in  "SCOMP:  A 
Solution  to  the  Multilevel  Security  Problem  and  its  translation  into  the 
TCB  given  in  "SCOMP  Trusted  Computing  Base."  The  interfaces  between 
the  TCB  modules  are  described  in  the  several  Part  II  specifications, 

"Detail  Specification  for  SCOMP  Kernel  Parti,  Release  2-1 
"Detail  Specification  for  SCOMP  Kernel  Part  II,  Release  2.1 

A  formal  description  of  the  security  policy  model  (Bell-La  Padula)  that  is 
enforced  by  the  TCB  is  given  in  "Secure  Computer  Systems  ,  for  the  general  case  and 
Multics  in  particular  in  "Computer  Security  Model:  Unified  Exposition  and 
MULTICS  Interpretation".  The  Bell-La  Padula  Model  has  been  accepted  by  the 
National  Computer  Security  Center  to  model  security  policy  Security  Requirements 
for  Automatic  Data  Processing  Systems"  and  to  be  consistent  with  its  axioms.  An 
interpretation  of  the  model  for  the  SCOMP  system  is  given  in  SCOMP 
Interpretation  of  the  Bell-La  Padula  Model." 

The  specific  TCB  protection  mechanisms  are  1)  protection  ring^ ,  2)  SPM 
mediation  of  per  user  virtual  memory,  3)  minimum  privilege  for  each  TCB  function, 

4)  integrity  levels  for  users,  operators,  administrators,  and  security  administrators 

5)  individual  trusted  software  processes  for  separate  functions,  and  6)  ring  gates  and 
checks  on  parameter  passing.  The  Part  H  Specifications  previously  referenced 
provide  the  necessary  documentation  for  satisfaction  of  this  requirement.  The 
explanation  given  to  show  that  the  TCB  protection  mechanisms  satisfy  the  model 
appears  in  "SCOMP  Interpretation  of  the  Bell-La  Padula  Model. 

Section  3  of  "SCOMP  Trusted  Computing  Base"  describes  the  SCOMP  TCB 
reference  monitor  implementation.  An  analysis  of  the  Reference  Monitor  appears  in 
Appendix  C  and  concludes  that  the  informal  proofs  that  the  SCOMP  system 
implements  the  reference  monitor  concept  are  adequate. 
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The  TCB  implementation  was  shown  to  be  consistent  with  the  FTLS  by 
specification  to  source  code  mappings 

"FTLS  to  Code  Mapping  for  the  SCOMP  Kernel  Software" 

"FTLS  to  Code  Mapping  for  SCOMP  Trusted  Software" 

"Justification  for  Unspecified  Code  for  the  SCOMP  Kernel  Software, 
Release  2.1" 

"Justification  for  Unspecified  Code  for  SCOMP  Trusted  Software" 

TCB  testing  is  documented  in: 

"SCOMP  Kernel  Test  Procedures" 

"SCOMP  Kernel  Functional  Test  Summary" 

"Kernel  Software  Test  Report  for  the  SCOMP,  Release  2.1" 

"Trusted  Software  Test  Plan  for  the  SCOMP" 

"Trusted  Software  Test  Report  for  the  SCOMP,  STOP  Release  2.0" 

"Trusted  Software  Test  Report  for  the  SCOMP,  Appendix  A:Test 
Programs,  Appendix  B:  Test  Results" 

"SCOMP  Test  and  Verification  Software  Description,  Rev.  3" 

The  TCB  structure  provided  added  assurance  of  the  validity  of  the  testing  and 
helped  to  demonstrate  the  implementation  of  least  privilege.  The  results  of  the 
covert  channel  analysis  including  conservative  bandwidth  estimates  are  presented 
in  "Covert  Channels  in  the  SCOMP  Kernel"  and  "Flow  and  Covert  Channel 
Analysis  for  SCOMP  Trusted  Software,  Release  2.1."  61  Auditable  events,  identified 
m  Section  13  of  "SCOMP  Trusted  Facility  Manual,  STOP  Release  2.1",  and  the 
scheme  of  randomly  selected  delays  on  exception  returns  appear  to  satisfactorily 
limit  the  utility  of  the  identified  covert  channels. 

Finally,  the  internal  TCB  mechanisms  that  are  not  security  related  and 
hence  not  dealt  with  in  the  FTLS  are  described  in  the  commercial  Honeywell  Level  6 
documentation  ("Honeywell  Level  6  Minicomputer  Systems  Llandbook,  CC71"  and 
"Honeywell  Level  6  Communications  Handbook,  AT97-02D"),  and  the  SCOMP 
system  unique  specifications: 

"Detail  Specification  for  SCOMP  Kernel  Parti.  Release  2.1" 

"Detail  Specification  for  SCOMP  Kernel  Part  H,  Release  2.1". 
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GLOSSARY 


Access 

A  specific  type  of  interaction  between  a  subject  and  an  object  that  results  m 
the  flow  of  information  from  one  to  the  other.[9] 

Access  Attribute 

Characteristic  of  an  access  of  an  object  that  specifies  possible  results  of  the 
access  Four  example  access  attributes  follow:  execute  (processing  based 
upon  the  object  accessed,  but  neither  altering  nor  viewing  _  capability); 
rpad  (viewing  but  not  altering  capability);  append  (altering  but  not 
viewing  capability);  and  write  (both  altering  and  viewing  capabilitiesUU 

Audit  Trail 

A  chronological  record  of  system  activities  that  is  sufficient  to  enable  the 
reconstruction,  reviewing,  and  examination  of  the  sequence  ot 
environments  and  activities  surrounding  or  leading  to  an  operation,  a 
procedure,  or  an  event  transaction  from  its  inception  to  final  results.Lyj 

Covert  Channel 

A  communication  channel  that  allows  two  cooperating  processes  to 
transfer  information  in  a  manner  that  violates  the  system  s  security  policy. 
Also  called  confinement  channel.[9] 

Covert  Storage  Channel 

A  covert  channel  that  involves  the  direct  or  indirect  writing  of  a  storage 
location  by  one  process  and  the  direct  or  indirect  reading  of  the  storage 
location  by  another  process.  Covert  storage  channels  typically  involve  a 
finite  resource  (e.g.,  sectors  on  a  disk)  that  is  shared  by  two  subjects  at 
different  security  levels. [5] 

Covert  Timing  Channel 

A  covert  channel  in  which  one  process  signals  information  to  another  by 
modulating  its  own  use  of  system  resources  (e.g.,  CPU  time)  m  such  a  way 
that  this  manipulation  affects  the  real  response  time  observed  by  the 
second  process. [5] 

Descriptive  Top, Level  Specification  (DTLS) 

A  top  level  specification  that  is  written  in  a  natural  language  (e.g., 
English),  an  informal  program  design  notation,  or  a  combination  ot  tne 

two. [5] 
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Formal  Security  Policy  Model 


A  mathematically  precise  statement  of  a  security  policy.  To  be  adequately 
precise,  such  a  model  must  represent  the  initial  state  of  a  system  ,  the  way 
in  which  the  system  progresses  from  one  state  to  another,  and  a  definition 
of  a  "secure"  state  of  the  system.  To  be  acceptable  as  a  basis  for  a  TCB,  the 
model  must  be  supported  by  a  formal  proof  that  if  the  initial  state  of  the 
system  satisfies  the  definition  of  a  "secure'  state  and  if  all  assumptions 
required  by  the  model  hold,  then  all  future  states  of  the  system  will  be 
secure.  Some  formal  modeling  techniques  include:  state  transition  models, 
temporal  logic  models,  denotational  semantics  models,  algebraic 
specification  models.  An  example  is  the  model  described  by  Bell-La 
Padula.[9] 

Formal  Top  Level  Specification  (FTLS) 

A  top  level  specification  that  is  written  in  a  formal  mathematical  language 
to  allow  theorems  showing  the  correspondence  of  the  system  specification 
to  its  formal  requirements  to  be  hypothesized  and  formally  proven. [9] 

Least  Privilege 

This  principle  requires  that  each  subject  in  a  system  be  granted  the  most 
restrictive  set  of  privileges  needed  for  the  performance  of  authorized  tasks. 
The  application  of  this  principle  limits  the  damage  that  can  result  from 
accident,  error,  or  unauthorized  use. [9] 


Object 


A  passive  entity  that  contains  or  receives  information.  Access  to  an  object 
potentially  implies  access  to  the  information  it  contains.  Examples  of 
objects  are:  records,  blocks,  pages,  segments,  files,  directories,  directory 
trees,  and  programs,  as  well  as  bits,  bytes,  words,  fields,  processors,  video 
displays,  keyboards,  clocks,  printers,  and  network  nodes. [9] 

Reference  Monitor  Concept 

An  access  control  concept  that  refers  to  an  abstract  machine  that  mediates 
all  accesses  to  objects  by  subjects. [9] 

Security  Kernel 

The  hardware,  firmware,  and  software  elements  of  the  Trusted  Computing 
Base  that  implement  the  reference  monitor  concept.  It  must  mediate  all 
accesses,  be  protected  from  modification,  and  be  verifiable  as  correct.[9] 

Security  Level 

The  combination  of  hierarchical  classification  and  a  set  of  nonhierarchical 
categories  that  represents  the  sensitivity  of  information. [9] 

Security  Mechanism 

A  system  or  means  of  implementing  a  security  service  within  a  system. 
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Security  Policy 

The  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization 
manages,  protects,  and  distributes  sensitive  information. [9] 

Security  Policy  Model 

A  formal  presentation  of  the  security  policy  enforced  by  the  system.  It 
must  identify  the  set  of  rules  and  practices  that  regulate  how  a  system 
manages,  protects,  and  distributes  sensitive  information. [9] 


Security  Service 

A  system  or  method  of  providing  a  security  relevant  feature  in  the  system. 
Sensitivity  Label 

A  piece  of  information  that  represents  the  security  level  of  an  object. 
Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for  mandatory  access 
control  decisions.[9] 


Subject 

An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device  that 
causes  information  to  flow  among  objects  or  changes  the  system  state. 
Technically,  a  process/domain  pair.[9] 

Trusted  Computing  Base  (TCB) 

The  totality  of  protection  mechanisms  within  a  computer  system  -- 
including  hardware,  firmware,  and  software  —  the  combination  of  which  is 
responsible  for  enforcing  a  security  policy.  It  creates  a  basic  protection 
environment  and  provides  additional  user  services  required  for  a  trusted 
computer  system.  The  ability  of  a  trusted  computing  base  to  correctly 
enforce  a  security  policy  depends  solely  on  the  mechanisms  within  the 
Trusted  Computing  Base  and  on  the  correct  input  by  system 
administrative  personnel  of  parameters  (e.g.,  a  user’s  clearance  level) 
related  to  the  security  policy.[9] 
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